The IP Multimedia Subsystem (IMS) is the technology defined by the Third Generation Partnership Project (3GPP) to provide IP Multimedia services over telecommunication networks. The IMS allows a telecommunications system to offer multimedia services to user terminals (referred hereinafter as “user equipment” (UE)). For example, these services can comprise voice, video, text, chat, and combinations thereof. To do so, IMS provides key features to enrich the end-user person-to-person communication experience through the integration and interaction of services. IMS allows new rich person-to-person (client-to-client) as well as person-to-content (client-to-server) communications over an IP-based network. The IMS is able to connect to both PSTN/ISDN (Public Switched Telephone Network/Integrated Services Digital Network) as well as the Internet. In relation to an IMS, a UE may be any device, mobile or stationary, enabled to communicate by radio or any other means with the IMS via an IP-CAN, for instance but not limited to e.g. mobile phone, smart phone, sensors, meters, vehicles, household appliances, medical appliances, media players, cameras, or any type of consumer electronic device, for instance but not limited to television, radio, lighting arrangements, tablet computer, laptop, or PC.
The IMS makes use of the Session Initiation Protocol (SIP) to set up and control calls or sessions between UEs (or UEs and application servers). The Session Description Protocol (SDP), carried by SIP signalling, is used to describe and negotiate the media components of the session. Whilst SIP was created as a user-to-user protocol, IMS allows operators and service providers to control user access to services and to charge users accordingly.
FIG. 1 illustrates schematically the architecture for the IMS and its relationship to an IP-Connectivity Access Network (IP-CAN). In the IMS Core Network, Call/Session Control Functions (CSCFs) operate as SIP proxies, and interface with other entities such as Border Gateway Control Functions (BGCFs) and Media Resource Function Controllers (MRFCs) amongst others. The 3GPP architecture defines three types of CSCFs, and there can be multiple instances of each type of CSCF within an operator's network. A Proxy CSCF (P-CSCF) is the first point of contact within the IMS for a UE; a Serving CSCF (S-CSCF) provides services to the subscriber; an Interrogating CSCF (I-CSCF) identifies the correct S-CSCF and forwards to that S-CSCF a request received from a UE via a P-CSCF.
The Home Subscriber Server (HSS) is the main database in the IMS for storage of subscriber and service related data, including user identities, registration information, access parameters and the Initial Filter Criteria (IFC) used to trigger services. For example, the HSS provides support to the IMS nodes/functional entities implementing call and/or session functionalities in order to complete the routing/roaming procedures by solving authentication, authorization, naming/addressing resolution, location dependencies, etc. The HSS also contains functionality of a Home Location Register and Authentication Centre (HLR/AUC) to provide support to packet-switched domain entities, such as the Serving GPRS Support Node (SGSN) and Gateway GPRS Support Node (GGSN), and to circuit switched domain entities, such as the Mobile Switching Centres (MSC).
Within the service layer of the IMS network, Application Servers (ASs) are provided for implementing IMS service functionality. Application Servers provide services to end users in an IMS system, and may be connected either as end-points over the 3GPP defined Ma interface, or “linked in” by an S-CSCF over the 3GPP defined ISC interface. In the latter case, Initial Filter Criteria (IFC) are used by an S-CSCF to determine which Applications Servers should be “linked in” during a SIP Session establishment (or indeed for the purpose of any SIP method, session or non-session related). The IFCs are received by the S-CSCF from an HSS during the IMS registration procedure as part of a user's Subscriber Profile.
Although the network nodes in the IMS Core Network should have a very high availability, some maintenance downtime and occasional failures are unavoidable. In addition, the communication links between the network elements are also subject to failures. For this reason 3GPP TS 23.380 specifies a set of standardized procedures for automatic restoration after loss or corruption of data, including restoration procedures for scenarios in which an S-CSCF, which was successfully assigned to serve a UE during registration of the UE, fails to process further signalling relating to a service for said UE. In particular, section 4.4.2 of 3GPP TS 23.380 describes a first scenario in relation to a session originating at the UE in which the S-CSCF that was assigned to serve the UE after the successful registration of the UE has lost all the user related data to the UE or it is unable to trust the store data (e.g. due to a restart). Section 4.4.3 of 3GPP TS 23.380 then describes a second scenario in relation to a session originating at the UE in which the S-CSCF that was assigned to serve the UE after its successful registration becomes unreachable (e.g. due to internal error, or due a communication error).
By way of example, FIG. 2 is a signalling flow diagram illustrating an example of an implementation of the restoration procedures defined in section 4.4.2 of 3GPP TS 23.380 relating to the scenario in which an S-CSCF has lost all the data related to the user. The steps performed are as follows:    S101. The (originating) UE sends a SIP INVITE message to the P-CSCF that is serving the user in order to request establishment of an IMS session.    S102. The serving P-CSCF receives the SIP INVITE, and forwards the SIP INVITE message to S-CSCF 1, which was assigned to the UE during registration. In this regard, the P-CSCF will have learnt the identity of S-CSCF 1 from the Service-Route header fields received during the registration procedure.    S103. S-CSCF 1 receives the SIP INVITE. However, as S-CSCF 1 has lost all the data related to the UE, S-CSCF 1 attempts to obtain the user profile from the HSS. To do so, S-CSCF 1 sends a Diameter Server-Assignment-Request (SAR) message to the HSS with the Server Assignment Type set to NO_ASSIGNMENT, in order to register a user identity of the user.    S104. The HSS receives the SAR message, and checks whether the S-CSCF requesting the user profile is assigned for the user. In this example, the HSS determines S-CSCF 1 is no longer assigned to the user, as another S-CSCF (S-CSCF 2) has been subsequently been assigned to the user (i.e. as S-CSCF 2 has been assigned to the user as a result of a terminating session that occurred after the failure of S-CSCF 1).    S105. The HSS therefore responds to the SAR message by sending a Diameter Server-Assignment-Answer (SAA) message to S-CSCF 1 with the Result-Code set to DIAMETER_UNABLE_TO_COMPLY, thereby indicating that the request has been unsuccessful for unspecified reasons.    S106. S-CSCF 1 receives the SAA message from the HSS and, as a result, returns a SIP 504 message in response to the SIP INVITE.    S107. S-CSCF 1 routes the SIP 504 message back to the UE via the serving P-CSCF.    S108. The UE receives the SIP 504 message and, as a result, the UE initiates a new initial registration to the IMS by sending a SIP REGISTER message.    S109. The serving P-CSCF receives the SIP REGISTER message and forwards the SIP REGISTER message to a I-CSCF.    S110. The I-CSCF receives the SIP REGISTER message and therefore sends a Diameter User-Authorization-Request (UAR) message to the HSS.    S111. The HSS receives the UAR message, and responds with a Diameter User-Authorization-Answer (UAA) message including the identity of the S-CSCF currently assigned to the user (i.e. S-CSCF 2).    S112. The I-CSCF receives the UAA message including the identity of S-CSCF 2 then forwards the SIP REGISTER message to S-CSCF 2.    S113. S-CSCF 2 receives the SIP REGISTER message, and responds with a SIP 200 OK message that includes the identity of S-CSCF 2 in the Service-Route header fields.    S114. The I-CSCF routes the SIP 200 OK message (including the Service-Route) back to the UE via the serving P-CSCF.    S115. The serving P-CSCF receives the SIP 200 OK message, saves the list of service route values in the Service-Route header fields, and forwards the 200 OK message to the UE.    S116. The UE then re-sends the SIP INVITE message in order to request establishment of the IMS session.    S117. The serving P-CSCF receives the SIP INVITE, and forwards the SIP INVITE message to S-CSCF 2, which is the S-CSCF identified in the list of service route values obtained from the Service-Route header fields of the SIP 200 OK response received in step S115.
According to 3GPP TS 23.380 (e.g. chapters 4.4.2 and 4.4.3), both of these scenarios can require that an S-CSCF returns an error response to the UE (i.e. using a SIP 504 response) in order to trigger the UE to initiate a new registration with the IMS. In this regard, 3GPP TS 24.229 (section 5.1.2A.1.6) and 3GPP TS 29.228 (section 6.1.2.1) specify, respectively, the SIP error code to be supported by these UEs (i.e. SIP message with error code “504”, received by a UE from a P-CSCF), and the DIAMETER protocol error code to be supported by the S-CSCFs (i.e. DIAMETER protocol error code “DIAMETER_UNABLE_TO_COMPLY”, received from a S-CSCF from a HSS, and which causes it to send a SIP message with error code “504” towards the P-CSCF, which is then to be forwarded towards the UE).
In short, the conventional restoration procedures disclosed by the 3GPP specifications require that, when the S-CSCF assigned to a user during registration with the IMS cannot process an IMS session for the user (e.g. because the S-CSCF has lost all user data following a failure or it is unable to trust any data after it resumes operation—as is the case illustrated in FIG. 2, chapter 4.4.2 of 3GPP TS 23.380-, or because the S-CSCF does not respond—e.g. chapter 4.4.3 of 3GPP TS 23.380), the UE must initiate a new registration with the IMS, such that a S-CSCF will be reassigned to the user (which can be the same assigned for its earlier registration, or a new one).
These restoration procedures therefore assume that the UE is able to receive and process a SIP 504 message received in response to a session establishment request, and that the processing of the SIP 504 message by the UE will result in the UE initiating a new registration with the IMS. However, this will not always be possible. In particular, it may not be possible for SIP signalling to transparently reach the UE, and/or the UE may not be SIP-capable. For example, the UE could be a circuit-switched UE that connects to the IMS via Mobile Softswitches (MSS), or even if the UE is SIP-capable, the UE may be connected to the IMS via Session Border Controllers (SBCs) that do not allow full transparent SIP signalling and that therefore might prevent a SIP 504 message from reaching the UE. In addition, even if the SIP signalling can reach the UE and the UE is SIP capable, the UE may not be configured to interpret a SIP 504 message as requiring the UE to initiate a new registration with the IMS. It would therefore be desirable to provide an alternative mechanism that for implementing IMS restoration that does not require the support of the UE.